Prior art database systems experience performance issues and sometimes even malfunction (e.g., hang, premature abort, data loss, and other malfunctioning) when a database server is improperly shutdown and/or restarted. One existing solution to address this problem is to rely upon database administrators to follow a predetermined procedure and/or executed a predetermined script stored on the database server whenever a shutdown command is desired, instead of directly submitting a native command to immediately shutdown the database server. For example, the script could be a MS-DOS batch file (e.g., with a .bat extension) that consists of a series of pre-processing commands concluding with a shutdown command for the database engine. Such solutions include various drawbacks and shortcomings leaving much room for improvement.
Companies, including financial businesses, manufacturing companies, and service-related businesses, often store and maintain databases in distributed or stand-alone form that are supported by numerous database servers. The database servers may be virtually or physically different and may reside at the same or different physical locations. The number of database servers may be very large, spanning tens, hundreds, or even thousands of physical and/or virtual computing machines. Consequently, a company may assign different database servers to different database administrators so that the each database server can be accessed and maintained in a reasonable manner. However, with the partitioning of database server responsibilities, a database administrator sometimes must expend an inordinate amount of time to adequately monitor (e.g., shutdown/reboot/restart) assigned database servers on a recurring basis.
With traditional systems, a database administrator may investigate a particular database server for relevant status information by manually logging into an identified database server and performing health checks, one server at a time. To the extent this requires a sequence of steps to be performed on the server, the process can be time consuming and cumbersome. Needless to say, the above-described process further reduces the productivity of the database administrator. Moreover, the number of generated status indications is often quite large and many indications may be irrelevant to the proper operation (e.g., shutdown, reboot, and/or restart) of a database service. Consequently a database administrator may spend a substantial amount of time on a database server that does not need further investigation.